Issues

• Instance Evacuation is causing shuffling after dropping an evacuated node. This is a result of new baseline being computed.

Description

We are now controlling the filtering of certain "Assignable" instances through the BaseControllerDataProvider. This will help centralize the logic and decouple it with the rebalancers. This PR migrates EVACUATE to this approach. Putting this logic here, allows methods like getAssignableInstanceConfigMap to respect the "Assignable" states. When the return value for this changes, a new baseline is computed. If it differs, which it will for evacuate, it will cause shuffling.

When the baseline is calculated, whether it is enabled, live, or set to EVACUATE is not respected. The assignment assumes the "happy path" where all of these instances are assignable or will be assignable. When and EVACUATE node is dropped, it will force a differing baseline to be calculated. This will cause shuffling after the evacuation is complete.

To fix this, setting and InstanceOperation to EVACUATE will ensure that it does not get returned in getAssignable*. This forces the baseline to be recomputed without considering the EVACUATE instance. When the instance is dropped, the arguments to baseline computation are the same as the previous computation and there is no change.

To maintain N -> N + 1 -> N behavior, we change the computeBestPossiblePartition state to pass all liveInstances so that the replicas on the EVACUATE instance can still be part of the stateMap until the new replica is created.

Tests

• Update testEvacuate to ensure no additional shuffling after the evacuated instance is dropped.

Changes that Break Backward Compatibility (Optional)

• Removed some public methods; however, they were relatively new and would likely cause more confusion if they were left. If objections, I can deprecate them instead. Also, I don't think any were part of an open-source release.

Documentation (Optional)

NA

Commits

• My commits all reference appropriate Apache Helix GitHub issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Code Quality

• My diff has been formatted using helix-style.xml
  (helix-style-intellij.xml if IntelliJ IDE is used)